REMARKS 



The Examiner has required new drawings. Accordingly, new drawing sheets 1/7 - 
7/7 are attached. No new matter is being introduced thereby. 
5 Claims 1 and 10 have been objected to, These claims are hereby amended and this 

ground of objection has been rendered moot. 

Claims 1, 5, 6, 10, 11,13, and 14 have been rejected under 35 ILS,C. 102(b) as 
anticipated by Sassa (U.S. patent 6,098,077); claims 1-4, 10, and 12 have been rejected 
under 35 U.S.C. 102(e) as anticipated by Gonzalez et al. (U.S. patent 6,684,289); claim 7 
1 0 has been rejected under 35 U.S.C, 1 03(a) as obvious over Sassa in view of Peterman 

(U.S. patent 5,623,654); and claim 8 and 9 have been rejected under 35 U.S.C. 103(a) as 
obvious over Sassa in view of Lasser (U.S. patent 6,883,1 14). 

In an effort to materially advance prosecution of this application, claim 1 has been 
amended to include the limitations of claims 6, 8, and 9, and other limitations. Claim 10 
15 has been amended to include the limitation of claim 1 1 . Accordingly, claims 6, 8, 9, and 
1 1 have been cancelled. New claims 15-17 have been added, 

The First Anticipation Rejection (Sassa) 

In the first place, Sassa does not address the smart card controller memory 

20 problem that is solved by the present invention. The Sassa focus is flash memory which, 
within Applicant's knowledge, is installed in memory cards in digital cameras, mobile 
phones, and the like, which memory cards may be exchanged. A memory stick according 
to Sassa provides a mass memory to any described digital device. By contrast, the present 
invention concerns a smart card controller. Claim 1 very expressly calls for a method in a 

25 "persistent memory." Sassa has no reference whatsoever to a persistent memory, only a 
flash memory. 

In accordance with the present invention, as claimed, a smart card controller uses 
the memory provided on a smart card for internal use only and for the storage of its own 
data in this memory. Thus, the controller serves for the management of a smart card. For 
30 reference purposes, a smart card is a digital data carrier with specific safety devices as a 
protection against unauthorized access on data stored on the smart card. Also, a smart 
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card is characterized in that any desired parts of a program (program capable of being 
operated) are stored on the smart card capable of being operated and use memory space. 
In the scope of this invention, a problem being solved is to manage this very small 
memory space as effective as possible. 
5 For example, such smart cards may be provided as bank cards, on which cards 

sensitive account data of an account holder, relevant passwords, relevant keys for having 
access on the card, and the like, are stored. 

The problem of a sensible management of memory, that is, that a great quantity of 
data shall be stored on a very limited memory, cannot at all be perceived from Sassa. It is 
10 important for Sassa that a mass memory having a specific memory volume may be read 
and written. 

It is true that it is also possible to store a program capable of being operated on 
such mass memory as described by Sassa. However, it is impossible to have this program 
capable of being operated under the control of such mass memory because the necessary 

15 controller intelligence is missing. 

In the case of a smart card in accordance with the present invention, on a 
relatively small card having the size of a check card and which may be easily carried by 
the user, those sensitive bank data, relevant keys, and all access authorizations are stored 
and kept ready for operational purposes. 

20 Applicant respectfully disagrees with the Examiner that step b) "selecting the size 

of blocks ..." is shown or suggested by Sassa. From column 6, lines 25-3 0 of Sassa, it is 
seen only that there are a plurality of blocks, each block comprising pages and each page 
having the fixed length or size of 528 bytes, with no variable selectable length of such 
blocks. By contrast, the blocks in the present claimed invention are selected "such that it 

25 is equal to, or equivalent to an integer ratio of, the length of a page in EEPROM to the 
physical size of the pages of the EEPROM memory existing on the card." Thus claim 1 
calls for the size of the blocks to be selected so that they fit into the physical EEPROM 
memory, which is not discernable from Sassa. 

Steps d) and e) of amended claim 1, corresponds to the limitations to original 

30 claim 8 and 9. With the method of claim 1 it is possible to provide a minimization of the 
amount of memory where, at the same time, a safer writing mechanism is used because 
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commit bits and commit blocks are utilized. Stated another way, claim 1 defines a 
method for memory management on smart card controllers so that it is possible to 
provide a safer writing cycle with a minimization of the amount of memory. 

The data safety aspects of the invention, as now resulting from the commit bits 
5 and commit blocks of claim 1, as amended, are supported in the specification, including 
but not limited to, page 3, last two paragraphs, to page 4, first two paragraphs, "The 
Commit Block" (page 9), together with Figure 4 and the corresponding description from 
line 18 on page 12 to line 9 on page 13. The new limitations in the f) paragraph of claim 
1 are from original claim 6, while 1), 2), and 3) are supported from the specification, page 

10 14, lines 23-30, and limitation g) is supported by page 13, lines 1-9. 

With reference to Figures 1 and 2 of Sassa, a so-called memory stick is described, 
including the method of how to store the data of a video camera or of another picture data 
file in this memory. Page memory 32 is used to store each page of the video data 
temporarily, which data are supplied by sequencer 31. With the help of decoder 34 an 

1 5 error-correcting code is assigned to the video data which are stored in page memory 32, 
In this way the video data are read in page-by-page by host computer 10 in flash 
memories 22a through 22d. In accordance with column 7, line 1 1 and the following, flash 
memory 22 is described as a plurality of individual memory blocks which are overwritten 
with a boot area and provide a data area which consists of several blocks. In addition, a 

20 further data area is existing having administrative information of several blocks. 

Applicant's invention, as described and claimed, has nothing in any way related to 
a boot area with a so-called boot block. This is an example of the different focus of Sassa 
as compared with the present invention. 

Additionally, while Sassa discloses organization in the form of a BAT, it does not 

25 address the improved safety in writing and management of the blocks with the help of 
commit blocks as called for in amended claim 1 . The memory stick of Sassa does not 
disclose or suggest a safe memory processing system and, therefore, it is not applicable to 
a smart card, to which Applicant's invention and claim 1 (as well as other claims) are 
addressed. 

30 Claims 5 and 6 depend from claim 1 and are believed to be free of the Sassa 

reference at least for the same reasons as is claim 1 . 
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Claim 10, and subclaims 13 and 14 (the limitations of claim 1 1 have been 
incorporated into claim 10), are directed to a device with a persistent memory and a block 
structure. Claim 10 requires "blocks with the same length and identifying them by their 
5 logical block number (LBN)." The Examiner refers to Sassa, column 1, lines 35-41, and 
column 9, lines 10-18, as disclosing this limitation. Applicant has studied the cited 
passages of Sassa and found no reference to the relative lengths of blocks, nor any 
reference to persistent memory anywhere in this cited document. 

Further, claim 10, as amended, includes the limitation of "a linkage between 

10 blocks by writing the LBN of the following block to the header of the leading one." The 
Examiner points to Sassa, column 6, line 39, to column 7, line 5, as showing this element. 
Applicant has carefully read this passage in Sassa and does not find any reference at all to 
a linkage with the identified function. This portion of Sassa relates to overwriting the 
"block enabled/disabled information" to indicate that the block cannot be used and talks 

15 about a "linkage address" and a "block end flag." Applicant found no reference to 
"writing the LBN of the following block to the header of the leading one." 

The Second Anticipation Rejection (Gonzalez) 

Claim 1, as amended, incorporates the limitations of originally submitted claim 8 
20 and 9. Like Sassa, Gonzalez has nothing which shows or suggests the security aspects of 
the commit bits and commit blocks. Further, while the Examiner has determined that 
"Gonzalez teaches a method for memory management in smart card controllers," 
Applicant could find no support in this reference for such a conclusion. There do not 
appear to be any references in Gonzalez to "memory management" or to "smart card." 
25 These differences in the method of claim 1, being neither shown nor suggested by 

Gonzalez, strongly support a finding of patentability. 

Claim 2-4 depend from claim 1 and are believed to be patentable at least for the 
same reasons as is claim 1. 

Claim 10 calls for "blocks with the same length and identifying them by their 
30 logical block number (LBN)." Applicant could find no reference to this limitation in 
Gonzalez. Further, as with Sassa, Applicant could find no reference or suggestion in 
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Gonzalez of "a linkage between blocks by writing the LBN of the following block to the 
header of the leading one " Thus, Applicant believes claim 10, as amended, patentably 
defines over Gonzalez, 

Claim 12 depends from claim 10 and is believed to be patentable for at least the 
5 same reasons as is claim 10. 

The First Obviousness Rejection (Sassa and Peterman) 

Claim 7 depends from claim 1. Peterman fails to supply the teachings missing 
from Sassa in relation to claim 1. Thus, claim 7 is believed to be patentable for at least 
10 the same reasons as is claim 1 , 

The Second Obviousness Rejection (Sassa and Lasser) 

These claims (8 and 9) have been cancelled, so this rejection is moot. 

15 New Claims 15-17 

New claim 15 is patterned after claim 1 but does not include the steps of replacing 
individual memory blocks and the last paragraph relating to commit bits and commit 
blocks. However, the arguments with respect to Sassa and Gonzalez apply here with 
respect to persistent memory, selecting the size of blocks, and the safety or security 
20 aspects of the commit blocks and commit bits. 

New claim 16 depends from claim 15 and adds that the commit bits are managed 
on a physical level This is supported by page 3, lines 26-30, page 9, lines 1-28, page 12, 
lines 18-32, and references throughout to "physical block number" (PBN). 

New claim 17 depends from claim 1 and is patterned after claim 16. This claim is 
25 believed to be patentable at least for the same reasons as is claim 1 . 
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CONCLUSION 

In view of the above claim amendments and arguments, it is believed that all the 
claims now pending in this application are in condition for allowance, and 
5 reconsideration is requested. Should any issues remain unresolved, Examiner Patel is 
invited to telephone the undersigned attorney. 



The Maxham Firm 
A Professional Corporation 
9330 Scranton Road, Suite 350 
San Diego, California 92121 
Telephone: (858) 587-7659 
Facsimile: (858) 587-7658 



Respectfully submitted, 
RainerNASE 




Registration No. 24,483 
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